IBIS Macromodel Task Group Meeting date: 27 August 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: * Ambrish Varma Ken Willis * Kumar Keshavan Intel: Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki * Ming Yan Stephen Slater Maziar Farahmand Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte SPISim: * Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad noted that Walter had asked to introduce a new topic: Enabling Back Channel Interface in statistical mode. - Randy noted that the authors of BIRD198 had sent a new draft to Arpad, Bob, Randy and Mike L. Arpad suggested that those who had received a copy review it and present a summary to ATM at next week's meeting. ATM could potentially provide some feedback prior to any formal submittal of BIRD198.1. Bob and Randy agreed. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the August 20 meeting. Ambrish moved to approve the minutes. Bob seconded the motion. There were no objections. ------------- New Discussion: Jitter HF/LF components and Jitter amplification: Michael Mirmak noted that his team is still working on this internally. He reiterated that they will not be pursuing the original draft's high-low approach and will instead pursue a spectral distribution approach. BIRD 197.4 discussion: Ambrish shared his latest version and asked to review it briefly then address email comments by Arpad and Fangyi. Ambrish noted some confusion about the "default" value of DC_Offset and said he hoped to address some of it with this sentence: If DC_Offset is Usage In, the EDA tool may use the input value of DC_Offset to post process the data returned by the AMI model. Ambrish discussed the concept of default values in terms of what the model assumes if the EDA tool doesn't provide a value when DC_Offset is In and what the tool assumes if DC_Offset is InOut and the model doesn't return a value. He said the simulation shouldn't stop if the model or tool doesn't provide the expected value at any point. Arpad objected to this concept and noted that DC_Offset is defined as Format Value and for those parameters the IBIS specification does not define a default. If the parameter is In then the tool must pass in a value, and if the parameter is InOut then the model must also return a value. Walter agreed and said there should be no concept of a default for DC_Offset. Randy noted that the "default" value language also existed in previous drafts. Ambrish removed any default value language to simply the text. Arpad had raised a question about the second sentence in the definition: ...output value of DC_Offset may return a different value by Rx AMI_Init. He said that the input value of DC_Offset was defined in the text as being the midpoint of the step response at the Rx pad. He noted that nothing in the text defined what output value of DC_Offset was and where it was. He noted that the output of Rx GetWave() is not at the Rx pad, it's at the core side of the Rx. If the output value of DC_Offset is with respect to Rx GetWave() output then it's on the core side, and the distinction compared to the input value must be defined. Fangyi noted that this was also the first question in his list. What is the definition of the output value of DC_Offset? Walter said the output value has only one possible meaning - the tool can choose to add that value to the Rx GetWave() output waveform, or not. That's the only use for the output value of DC_Offset. Fangyi agreed, but added that if we talk about an NRZ_Threshold later then it may have meaning there too. Walter said that for this BIRD (with NRZ_Threshold removed) the waveform output of Rx GetWave() is high if it's over zero and low if it's below zero. Walter suggested we could add language stating that the output value is at the latch to address Arpad's concern. Fangyi said we should instead restore the following sentence: The output value of DC_Offset returned by Rx AMI_Init is to be added to the Rx AMI_GetWave output waveform by EDA tools to form the complete waveform at the Rx algorithmic model output. He said this would define the output value of DC offset and the complete waveform. He noted that it was not important that it was "at the latch." Radek noted that "may return a different value" is redundant because that's the purpose of an Out parameter. Ambrish said the important part of that sentence was "by Rx AMI_Init". That's explaining that the value returned by AMI_Init() is the one for the EDA tool to use. Radek noted that "can be added" is ambiguous in this sentence: This returned value can be used by the EDA tool to post process data returned by the AMI model. He said that it "is" added to the Rx GetWave() output waveform to form the complete waveform. The only way to get the "complete waveform" is to add the output value of DC_Offset to the output of Rx GetWave(). Walter said he didn't know what "complete waveform" was, and what's important is the differential waveform at the latch. He said that as a convenience for waveform display we can add DC_Offset. Radek/Fangyi noted that "complete waveform" was defined as the sum of the output value of DC_Offset and the waveform returned by Rx GetWave() (in BIRD197.4). Walter said that definition is fine, but the EDA tool isn't obligated to display the "complete waveform". Arpad noted that it had been called physical waveform in earlier drafts. Arpad suggested new wording: The sum of the output value of DC_Offset and the Rx AMI_GetWave output waveform forms the complete waveform. Arpad's next question was triggered by this sentence: It is assumed that the waveform input to the Rx AMI_GetWave function is the physical Rx input waveform minus the input value of this DC_Offset. He noted that implicit in this sentence is the fact that the waveform input to Rx GetWave() has no DC offset. He said that in SERDES designs everything was difference based, but in the single-ended applications a Tx model maker may ask what the output of the Tx GetWave() function should be. Do we need to make a statement for Tx model makers? What if a Tx model maker knew the output would have some DC offset and designed their GetWave() to return a waveform with a DC offset? Wouldn't we risk compatibility issues with Rx GetWave() models expecting their input waveforms to have no DC_Offset? Walter noted that the output of Tx GetWave() should contain its equalization applied to the input stimulus waveform, which the spec defines to be between +-0.5V. If it's a decent Tx its output will be zero centered. Kumar noted that this BIRD is for the Rx only, and a model maker of the Tx or Rx would have no idea what this DC offset could be ahead of time, that's why this parameter is needed. Walter noted that a Tx .dll doesn't know how it's terminated, and it only gets an IR, so it can't possibly know anything else and must be centered around zero. Fangyi noted that the sentence that triggered Arpad's question is itself telling the Tx model maker not to add any DC_Offset to their GetWave() output waveform. Arpad thought it should be stated more clearly, but said we could move on if no one else thought it was necessary. Fangyi asked about this sentence: The Rx AMI_GetWave function may use this information, for example: ... He asked if this was meant to say GetWave or Init, since DC_Offset is passed into the Init() function. Walter noted that it was passed in to Init() but could also be used by GetWave(). Fangyi agreed, but asked if we needed this sentence at all. Ambrish said it was just there to give an example to explain and justify the need for the parameter, and that he was willing to remove it. Walter said the parameter has three primary uses: 1. When you go through a differential gain receiver, you might saturate. The only way for the model to know is with DC_Offset. 2. When the DFE slicer chooses to add voltage to the signal at the latch to correct for DFE, it could add something that causes it to go into saturation. The only way to know is with DC_Offset. 3. The value of VrefDQ is actually set by a register. It might be nice to know the actual value of DC_Offset vs. what the register setting could provide. Kumar said we should remove the sentence because it's too specific. Arpad agreed that it's redundant in the same way Radek had previously said that defining what an InOut parameter was used for was redundant. The group agreed to simplify the text by removing the sentence. Fangyi asked about this sentence: If DC_Offset is Usage In, the EDA tool may use the input value of DC_Offset to post process the data returned by the AMI model. He asked what the definition of post processing was. Randy said it was just to display the eye. Walter said an EDA tool can do whatever it wants with any Out parameter. We don't need to say it for every parameter. Ambrish noted that he had added this sentence to attempt to address one of Randy's questions about the "default" output value when DC_Offset was an In. Randy said we should remove this sentence since we'd removed the "default" language. Fangyi asked about this sentence: It is the responsibility of the EDA tool to perform any shifting of the output waveform. Fangyi and Radek noted that we should add "Rx GetWave()" in front of output. Radek asked what "responsibility" meant - do we want the EDA tool to do it, or does it have to? What is shifting, just adding the DC_Offset? Walter said the sentence should just be removed. Randy agreed and noted that we already say the output waveform must be nominally centered around 0V, so it's pretty clear. Arpad and Randy asked Ambrish to send out a new cleaned up version incorporating all the changes discussed in the meeting. Ambrish agreed. Bob noted that the vote on BIRD197.4 scheduled for the next Open Forum meeting will be delayed now. Fangyi said that with the changes made today, this new proposal is essentially BIRD197.4 with NRZ_Threshold removed and a minor difference in "default" values. - Randy: Motion to adjourn. - Radek: Second. - Arpad: Thank you all for joining. AR: Ambrish to send out a new draft of BIRD197.5 incorporating today's changes. ------------- Next meeting: 03 August 2019 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives